^ DISPOSITIF ET PROCEDE DE CONTROLE DE DONNEES DE GESTION 
D'EQUIPEMENTS DE RESEAU, POUR UN SYSTEME DE GESTION DE 
RESEAU DE COMMUNICATIONS 

Uinvention concerne le domaine de la gestion d'equipements d'un 
reseau de communications, et plus particuli^rement celui du controle de 
integration de nouveaux equipements de r6seau ou de nouvelles versions 
d'equipements de reseau par un syst^me de gestion de reseau. 

La plupart des reseaux de communications sont equipes d'outils 
couples a un systeme de gestion de reseau (ou NMS pour « Network 
Management System »), egalement appele systeme d'exploitation du reseau, 
permettant a leur gestionnaire (ou superviseur) de gerer les equipements qui 
les constituent. De tels outils mettent generalement en oeuvre des fonctions et 
des services, egalement appeles OAM&P (pour « Operations, Administration, 
Maintenance and Provisioning »). 

Un tel systeme de gestion de reseau est par exemple connu de la 
demande de brevet BP 0946020, au nom de la societe NTT. 

On entend ici par « equipement de reseau» tout type de materiel, 
comme par exemple des serveurs, des terminaux, des commutateurs, des 
routeurs ou des concentrateurs, capable d'echanger des donnees selon un 
protocole de gestion de reseau avec le systeme de gestion NMS, comme par 
exemple le protocole SNMP (pour « Simple Network Management Protocol » 
RFC 2571-2580). 

Lorsqu'un nouvel equipement (ou nouveau type d'equipement) est 
mis sur le marclie, il doit disposer d*un module de donnees de gestion, 
egalement appele application de gestion, afm de pouvoir etre integre dans un 
reseau et gere par son gestionnaire. L'integration consiste alors a charger 
dans un serveur du NMS le « nouveau » module de donnees de gestion 
associe a ce nouvel equipement. On entend ici par « nouvel equipement ». 
aussi bien un equipement existant modifie (par exemple par le remplacement 
ou Tajout d'une carte) qu'un equipement d'un nouveau type. 



Or, pour effectuer un tel chargement, il faut prealablement supprimer 
« Tancien » module de donnees de gestion utilise par le NMS pour gerer 
Tancien equipement, puis relancer rapplication de configuration de Tensemble 
du reseau. Ce mode de chargement presente au moins deux inconv6nients. 
Tout d'abord, pendant toute la duree de ces operations, les equipements du 
reseau ne peuvent plus etre geres par le NMS. Ensuite, le chargement d*un 
nouveau module de donnees de gestion ne garantit pas sa compatibilite avec 
les autres modules de donnees de gestion associes aux autres equipements 
g6r6s par le NMS. Par consequent, en cas dincompatibilite, il peut arriver que 
le nouvel equipement ne puisse pas se synchroniser avec le NMS, ce qui en 
interdit la gestion. Le superviseur (ou gestionnaire) du r6seau doit alors 
interrompre la gestion du reseau pour ^viter que des alarmes intempestives 
ne parviennent au NMS. 

Uinvention a done pour but de remedier a tout ou partie des 
inconvenients precites. 

Elle propose a cet effet un dispositif de controle de donnees de 
gestion d'equipements d'un reseau de communications equipe d'un systeme 
de gestion de reseau (NMS) capable de gerer les equipements de reseau a 
partir de modules de donnees de gestion pr6alablement charges, associes 
aux equipements de reseau et stockes dans une memoire. 

Ce dispositif se caracterise par le fait qu'il comprend des moyens de 
controle capables, lorsque le NMS effectue une demande de prise en charge 
d'au moins un nouvel equipement, d'extraire de la memoire le module de 
donnees de gestion qui est associe a chaque nouvel equipement, puis de 
charger dans le NMS chaque nouveau module de donnees de gestion extrait, 
de fagon dynamique, de sorte que la gestion, par le NMS, des autres 
equipements du reseau ne soit pas interrompue. 

Selon une autre caracteristique de Tinvention, les moyens de controle 
peuvent etre agences, chaque fois qu'est charge un nouveau module de 
donnees de gestion, associe a une nouvelle version d'un 6quipement qui n'a 
pas encore ete int6gree dans le reseau alors qu'un « ancien » module de 
donn6es de gestion associe a une version anterieure de cet equipement est 
encore charg6 et que la version anterieure est toujours int6gree au reseau, 
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tout d'abord pour mettre en attente le nouveau module de donnees de gestion 
venant d'etre charge de maniere d poursuivre la gestion de Tancienne version 
de Tequipennent d partir de Tancien module associ6 et charge, jusqu'a 
rintegration de la nouvelle version de I'equipement. Ensuite, lorsque les 
5 moyens de controle regoivent des donnees signalant rintegration de la 
nouvelle version, ils peuvent mettre en service le nouveau module de 
donnees de gestion precedemment charge de maniere a assurer la gestion 
de la nouvelle version de Tequipement a partir de celui-ci. 

Dans ce cas, il est preferable que la mise en attente consiste, d'une 

10 part, a permettre la gestion de la nouvelle version de Tequipement a partir du 
nouveau module de donn6es de gestion associe, sans tenir compte des 
eventuels messages d'erreur lies a sa non integration au sein du reseau, et 
d*autre part, a adresser a Tancien module de donnees de gestion un message 
lui signalant qu'un changement de version est en cours et qu'il ne doit pas 

15 tenir compte d'une partie au moins des messages d^erreur lies a la gestion 
conjointe des ancienne et nouvelle versions. 

Par ailleurs, et toujours dans le cas presente ci-dessus, il peut etre 
avantageux que les moyens de controle soient capables de supprimer (ou 
decharger) Tancien module de donnees de gestion une fois qu'ils ont ete 

2 0 avertis de la synchronisation entre la nouvelle version d'equipement et le 
nouveau module de donnees de gestion. 

En outre, les moyens de controle sont preferentiellement agences de 
maniere a charger des modules de donnees de gestion selon au moins un 
premier mode dans lequel les modules sont charges independamment 

2 5 d'eventuelles dependences entre eux et un second mode dans lequel les 
modules sont charges en tenant compte d'eventuelles dependences entre 
eux. 

Preferentiellement, chaque module de donn6es de gestion est 
constitue d'au moins un descripteur. Par definition, un descripteur est un 
30 module informatique qui contient toutes les donnees necessaires a la gestion 
par le NMS d'au moins un element d'equipement (comme par exemple une 
carte a circuits integres ou une interface de connexion). 

Preferentiellement, un descripteur est dedie a un equipement et 



> constitue, d'une part, de fichiers de codes de programmes, de preference en 
langage Java (en raison de son aptitude ^ charger et decharger des codes de 
fagon dynamique), dont un premier ensemble de fichiers permettant de mettre 
en oeuvre une interface d'equipement, un deuxieme fichier comportant des 
premieres donnees designant le type de Tequipement, et un troisieme fichier 
comportant des secondes donnees designant la definition de MIB associee a 
cet 6quipement, et d'autre part, d'au moins un fichier de configuration, par 
exemple de type XML et contenant des informations permettant de gerer un 
type d'^quipements du r^seau. 

L'invention porte 6galement sur un serveur de gestion de reseau de 
communications equipe d'un dispositif de controle du type de celui presente 
ci-avant et de moyens de gestion capables de gerer des equipements de 
reseau a partir de modules de gestion pr^alablement charges, associes aux 
equipements de reseau et stockes dans une memoire. 

Uinvention porte en outre sur un precede de controle de donnees de 
gestion d'equipements d'un reseau de communications, dans lequel on gere 
les equipements de reseau a partir de modules de donnees de gestion 
charges, associes a ces equipements de reseau. 

Ce precede se caracterise par le fait qu'il consiste, en cas de 
demande de prise en charge d'au moins un nouvel equipement du reseau, a 
charger de fagon dynamique chaque nouveau module de donnees de gestion 
associe a un nouvel equipement, de sorte que la gestion des autres 
equipements du reseau ne soit pas interrompue. 

Le precede selon Tinvention pourra comporter des caracteristiques 
complementaires qui pourront etre prises separement et/ou en combinaison, 
et en particulier : 

- en cas de chargement d'un nouveau module de donnees de gestion 
associe a une nouvelle version d'un equipement qui n'a pas encore 6te 
integr6e dans le reseau alors qu'un « ancien » module de donnees de 
gestion, associe a une version anterieure de cet Equipement, est encore 
charge et que cette version anterieure est toujours integree au reseau, il 
est avantageux de commencer par mettre en attente le nouveau module 
de donnees de gestion qui vient d'etre charge de maniere a poursuivre la 



gestion de Tancienne version de requipement d partir de rancien module 
associ6 et charge, jusqu'a I'integration de la nouvelle version de 
requipement, puis de mettre en service le nouveau module charg6 lorsque 
Ton regoit des donnees signalant rintegration de la nouvelle version, de 
sorte que la gestion de la nouvelle version de requipement soit assuree a 
partir de ce nouveau module de donnees de gestion ; 

- la mise en attente peut consister, d'une part, a permettre la gestion de la 
nouvelle version de requipement a partir du nouveau module de donnees 
de gestion associe, sans tenir compte d'eventuels messages d'erreur lies 
d sa non integration dans le reseau, et d'autre part, d adresser a Tancien 
module de donn6es de gestion un message lui signalant qu'un 
changement de version est en cours et qu'il ne doit pas tenir compte d'une 
partie au moins des messages d'erreur lies a la gestion conjointe des 
ancienne et nouvelle versions ; 

- en cas de synchronisation entre la nouvelle version d'equipement et le 
nouveau module de donnees de gestion, on peut supprimer I'ancien 
module de donnees de gestion ; 

- on peut charger les modules de donnees de gestion independamment de 
leurs eventuelles dependances ou en tenant compte de leurs eventuelles 
dependances ; 

- les modules de donnees de gestion peuvent etre chacun constitues d'au 
moins un descripteur du type de ceux presentes ci-avant. 

Uinvention peut notamment etre mise en oeuvre dans toutes les 
technologies reseaux qui doivent etre gerees, et notamment dans les reseaux 
de transmission (par exemple de type WDM, SONET, SDH), de donnees (par 
exemple de type Internet-IP ou ATM) ou de voix (par exemple de type 
classique, mobile ou NGN). 

D'autres caract6ristiques et avantages de Tinvention apparaTtront a 
I'examen de la description detaill^e ci-apres, et de Tunique figure annexee qui 
illustre de fagon schematique un exemple de reseau de communications 
equipe d'un dispositif de controle selon invention implante dans un serveur 
de gestion de reseau. Cette figure pourra non seulement servir a completer 
rinvention, mais aussi contribuer a sa definition, le cas echeant. 
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L'invention propose un dispositif de controle destine ^ permettre au 
gestionnaire (ou superviseur) d'un reseau de communications, via son 
syst6me de gestion du r6seau (ou NIVIS pour « Network Management 
System »), d'acceder rapidement aux donnees de gestion des equipements 
5 du reseau qu'il souhaite gerer et/ou configurer. 

Sur I'unique figure se trouve illustre. a titre d'exemple, un reseau de 
communications 6quipe d'un dispositif de controle 1 selon Tinvention. Plus 
precisement, dans cet exemple, le dispositif 1 est implants dans un serveur 
de gestion 2 du systeme de gestion du reseau NMS, qui comporte en outre un 

10 module de gestion 3, couple au dispositif 1 et a une interface graphique 4 de 
type GUI (pour « Graphical User Interface »). 

Bien entendu, le dispositif de controle 1 pourrait etre implante dans un 
bottler externe dedie, couple au serveur de gestion 2, ou bien dans le module 
de gestion 3 dudit serveur de gestion 2. Par ailleurs, dans I'exemple illustre, 

15 on n'a represents qu'un unique serveur de gestion 2, mais, on peut envisager 
que le NMS comporte plusieurs serveurs de gestion, chacun equipe d'un 
dispositif de gestion 1, et par exemple destines a permettre chacun la gestion 
d'une partie des equipements du reseau. 

Comme illustre, le reseau de communications comporte une 

20 multiplicite d'equipements de reseau 5 (ici au nombre de quatre, a titre 
d'exemple), tels que des serveurs peripheriques ou de coeur, des terminaux, 
des commutateurs ou des routeurs, capables d'echanger des donnees, selon 
un protocole de gestion de reseau choisi, avec le NMS et notamment avec 
son serveur de gestion 2. 

25 Par exemple. le reseau de communications est de type Internet (IP) et 

le protocole de gestion du reseau est le protocole SNMP (pour « Simple 
Network Management Protocol » RFC 2571-2580). Mais, bien entendu, 
rinvention s'applique a d'autres types de r6seau, comme par exemple aux 
reseaux de transmission de type WDM, SONET ou SDH, de donnees de type 

30 ATM, ou de voix de type classique, mobile ou NGN, et a d'autres protocoles 
de gestion de reseau, comme par exemple TL1 , CORBA ou CMISE/CMIP. 

Par ailleurs, chaque equipement 5 comporte classiquement une base 
d'informations de gestion 6 (ou MIB pour « Management Information Base »), 



egalement appel^e base d'instances d'objets. Chaque MIB 6 comporte des 
champs d'information dont les valeurs sp6cifiques caracterisent l'6quipement 
associe et peuvent etre acced6es par un navigateur 7, gen6ralement implante 
dans interface graphique 4. Par ailleurs, chaque MIB 6 est associee a une 
definition de base d'informations de gestion 8, egalennent appelee definition 
de MIB, stockee dans le NMS et accessible au serveur de gestion 2, et 
notannment a son module de gestion 3. Une definition de MIB 8 repond par 
exemple au standard RFC 1213, dans le cas du protocole SNMP, et decrit 
g§n6ralement, pour I'equipement 5 concerne, tous ses attributs possibles, un 
type de donnees (string, integer, ...). I'organisatlon de nommage, le texte 
decrivant Tequipement (ou objet), les droits d'acces, la hierarchie des objets 
(ou ^quipements), et analogue. 

En outre, on prevoit une memoire 9 coupl6e au moins au dispositif de 
controle 1 et dans laquelle sont stockees des modules de donnees de gestion 
dedies a chaque equipement 5 du reseau et preferentiellement agences sous 
la forme de ce que I'homme de I'art appelle des descripteurs. Un descripteur 
est un module informatique qui contient toutes les donnees necessaires a la 
gestion par le NMS d'au moins un element d*equipement (comme par 
exemple une carte a circuits integres ou une interface de connexion). 

Chaque descripteur d6die est preferentiellement constitue d'au moins 
un premier fichier de codes de programmes, de preference en langage Java, 
qui permet de mettre en oeuvre une interface d'equipement 5, un deuxieme 
fichier contenant des donnees qui designent un type d'6quipement, et un 
troisieme fichier contenant des donnees qui designent la definition de MIB 8 
associee a Tequipement du type considere, et d'au moins un fichier de 
configuration, par exemple de type XML, qui contient des informations 
permettant de gerer un type d'equipement 5 du reseau. 

Les fichiers de codes de programmes sont preferentiellement en 
langage Java, en raison de Taptitude de ce langage a charger et decharger de 
fagon dynamique des codes informatiques. Mais, d'autres langages peuvent 
etre envisages, comme par exemple Small Talk, des lors qu'ils permettent le 
chargement et le dechargement dynamique de codes informatiques. 

Dans le cas du langage Java, les fichiers de codes sont egalement 
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appeles « classes ». Cheque descripteur est done associ^ d une classe 
principale qui possede eventuellement certaines dependances avec d'autres 
classes. Par exemple un descripteur A peut §tre congu de maniere ^ 
fonctionner avec une version particuliere CA de la classe principale C, tandis 
qu'un descripteur B peut etre congu de maniere a fonctionner avec une 
version particuliere CB de cette classe principale C. 

Dans Texemple illustre, la memoire 9 est implantee dans le serveur de 
gestion 2. Mais, elle pourrait etre implantee dans le dispositif de contrdle 1 de 
rinvention, ou dans le module de gestion 3 du serveur 2, ou encore dans un 
boTtier exteme dedie, couple au moins au dispositif de controle 1 . 

Le dispositif de controle 1 comporte un module de controle 10 agence 
de maniere S extraire de la memoire 9 chaque descripteur dedie a un 
equipement 5 que le serveur de gestion 2 du NMS souhaite prendre en 
charge, puis a charger ce descripteur dedie extrait dans le module de gestion 
3 du serveur 2. Plus precisement, selon invention, le module de controle 10 
est capable de charger les descripteurs, de fagon dynamique, dans le module 
de gestion 3 de sorte qu'il puisse continuer a gerer les autres equipements du 
reseau sans etre interrompu (et perturbe) par I'operation de chargement. 

Lorsqu'un descripteur est charge dans le module de gestion 3, et que 
Tequipement 5 auquel il est dedie s'est synchronise ^ lui, via le reseau, le 
serveur de gestion 2, dans lequel il est implante, est alors capable de 
communiquer avec ledit equipement 5. Du fait de Tarchitecture utilisee, de 
type « client/serveur », le serveur de gestion 2 utilise generalement plusieurs 
strategies pour maintenir synchronisees les informations associees aux 
differents equipements 5 qu'il gere. II peut par exemple stocker les MIB 6 des 
equipements 5 dans une memoire cache et/ou dans un disque dur, ou 
transmettre toutes les requetes aux equipements 5, ou encore interroger 
regulierement (« polling ») les equipements 5, ou encore ecouter toutes les 
notifications qui lui parviennent du reseau. 

Les donn6es (ou codes) que comprennent les descripteurs et qui sont 
chargees (ou « plug in ») dans le module de gestion 3 permettent non 
seulement la gestion des equipements, mais egalement I'affichage de 
certaines au moins des informations relatives aux equipements 5 sur un 
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% moniteur coupl§ au serveur de gestion 2, grace a Tinterface graphique 4 de 
type GUI. 

De fagon classique, la gestion d'un equipement 5 au niveau du 
module de controle 3 s'effectue a I'aide de deux types de commandes. Un 
5 premier type concerne les commandes de creation qui permettent de 
configurer chaque equipement 5 avec les donnees qui lui sont specifiques, 
comme par exemple son type, sa version, son adresse, et analogues. Ces 
donnees sont stockees dans une memoire dedi^e a cet effet. Lors du 
lancement (ou d6marrage) du systeme de gestion, cette memoire est 

10 acc6dee pour permettre le chargement des descripteurs et des d6finitions de 
MIB appropries. Un second type concerne les commandes de supervision qui 
permettent au module de gestion 3 de synchroniser ses donnees avec celles 
des 6quipements 5. 

Plusieurs dizaines de descripteurs, typiquement jusqu'a cinquante 

15 environ, peuvent ainsi etre charges dans le module de gestion 3 et dans 
interface graphique 4, via le module de gestion 3. 

Le dispositif 1 selon invention est par ailleurs preferentiellement 
agence de maniere a gerer la coexistence au sein du module de gestion 3 
d'un ancien et d'un nouveau descripteurs associes a un meme type 

20 d'6quipement 5. En effet, avant d'integrer dans un reseau un nouvel 
equipement ou une nouvelle version d'un equipement, on charge dans le 
module de gestion 3 le nouveau descripteur qui lui est d6di6. Ce nouveau 
descripteur, dedie, par exemple, a la nouvelle version d'un 6quipement, 
coexiste done dans le module de gestion 3 avec I'ancien descripteur dedie a 

2 5 la version (dite ancienne) de cet equipement, laquelle est toujours integree 
dans le reseau, contrairement a la nouvelle. 

Pour eviter que cette coexistence ne perturbe la gestion effectuee par 
le module de gestion 3, notamment en raison d'alarmes signalant I'absence 
de la nouvelle version, le module de controle 10 est agence de maniere a 

30 placer dans un etat « d'attente » (ou « stand-by ») chaque nouveau 
descripteur qu'il vient de charger jusqu'a integration de la nouvelle version de 
I'equipement associe. De la sorte, le module de gestion 3 peut continuer a 
g6rer I'ancienne version de I'equipement a partir de Tancien descripteur 
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associe et charge tant qu1l demeure int^grS au r^seau. Ensuite, lorsque le 
module de contrdle 10 est avert! par le module de gestion 3 que la nouvelle 
version de Tequipement a bien ete integree au reseau, il place le nouveau 
module dans I'etat « actif » et Tancien descripteur dans Tetat « inactif ». Le 
nouveau descripteur est alors en service et le module de gestion 3 peut 
assurer la gestion de la nouvelle version de I'equlpement a partir de celui-ci. 

Uintegration est consideree comme definitive lorsque le module de 
gestion 3 est assure que les donnees (et informations) relatives au nouvel 
6quipement 5 sont effectivement synchronis6es avec les descripteurs d6di6s 
aux differents 6quipements du reseau. II peut en effet arriver qu'une nouvelle 
version d'6quipement (ou un nouvel equipement) ne soit pas compatible avec 
le systeme de gestion du r6seau. Dans cette situation, Tinvention permet done 
de s'assurer qu'un equipement est effectivement integre au reseau avant d'en 
assurer la gestion conjointement avec celle des autres equipements du 
reseau. 

Dans ce mode de realisation du dispositif de controle 1, il est par 
ailleurs preferable que le placement, par le module de controle 10, d'un 
nouveau descripteur dans Tetat d'attente consiste, d'une part, a faire croire au 
module de gestion 3 que la nouvelle version de Tequipement 5 a bien ete 
integree, et qu1l doit le gerer a partir du nouveau descripteur charge sans tenir 
compte des eventuels messages d'erreur lies a sa non integration effective au 
sein du reseau, et d'autre part, a adresser a Tancien descripteur un message 
lui signalant qu'un changement de version est en cours et qu'il ne doit pas 
tenir compte d'une partie au moins des messages d'erreur lies a la 
coexistence des ancienne et nouvelle versions. Ainsi, tant que les donnees 
d'un nouvel equipement n'ont pas ete effectivement synchronisees, le module 
de gestion 3 assure sa supervision, via le nouveau descripteur associe, selon 
un mode dit « esclave », par opposition a un mode dit « maitre » designant la 
supervision de Tancienne version encore synchronis§e via Tancien 
descripteur. 

Un tel mode de fonctionnement permet de r6duire notablement le 
temps necessaire a Tintegration de chaque nouvel equipement au sein d'un 
reseau. 
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Par ailleurs, lorsqu*un ancien descripteur a et6 plac6 dans I'etat 
inactif, et done que la nouvelle version de T^quipement a 6t6 consid^ree 
comme effectivement integr6e au r6seau (ses donnees etant synchronisees), 
il est preferable que le module de controle 10 le decharge du module de 
gestion 3. Ce dechargement peut consister en une suppression. 

Comme indique precedemment, le langage Java est particulierement 
interessant dans le cadre de la mise en oeuvre de I'invention, et notamment 
de la gestion de la coexistence d'ancien et nouveau modules de donnees de 
gestion (ou descripteurs). En effet, ce langage offre une fonctionnalite 
appelee chargement de classe (ou « classloader ») qui selon sa declinaison 
permet d'isoler ou de ne pas isoler des classes associees ^ des descripteurs 
differents selon que Ton souhaite tenir compte ou non de leurs eventuelles 
dependances respectives. Grace a cette fonctionnalite, il est done possible de 
ne charger qu'une fois une classe principale C pour tous les descripteurs (de 
maniere a tenir compte des dependances de ses sous-classes) ou de charger 
des sous-classes CA et CB, par exemple, de maniere a ne pas tenir compte 
de leurs dependances eventuelles (ce qui est avantageux lorsque certaines 
d6pendances sont incompatibles). 

Le module de controle 10 est done agence de maniere a fonctionner 
selon ces deux modes de chargement, en fonction du choix du superviseur. 

II est important de noter que ce mode de chargement n'est pas 
exclusif au langage Java. D'autres langages I'utilisent, comme par exemple 
C#. 

Le module de gestion 3, le dispositif de gestion 1 (et notamment son 
module de controle 10), ainsi qu'eventuellement la memoire 3, peuvent etre 
realises sous la forme de circuits electroniques (ou « hardware »), de modules 
logiciels ou informatiques (ou « software »), ou d'une combinaison de circuits 
et de logiciels. 

L'invention offre egalement un precede de controle de donnees de 
gestion d'equipements 5 d'un reseau de communications, dans lequel on gere 
les §quipements 5 de r6seau a partir de modules de donnees de gestion 
charges, associes a ces equipements de reseau. 

Celui-ci peut etre mis en oeuvre a I'aide du dispositif de controle 1 
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. presents ci-avant. Les fonctions principales et les sous-fonctions optionnelles 
assurSes par les etapes de ce procede etant sensiblement identiques a celles 
assurees par les diff6rents moyens constituant le dispositif de controle 1, 
seules seront resumees ci-apres les etapes mettant en oeuvre les fonctions 
principales du procede selon Tinvention. 

Ce procede se caracterise par le fait qu'il consiste, en cas de 
demande de prise en charge d'au moins un nouvel equipement 5 du reseau, 
d charger de fagon dynamique chaque nouveau module de donn6es de 
gestion (ou descripteur) associe ^ un nouvel equipement 5, de sorte que la 
gestion des autres ^quipements du reseau ne soit pas interrompue. 

Preferentiellement, en cas de chargement d'un nouveau module de 
donnees de gestion associe a une nouvelle version d'un equipement 5 qui n'a 
pas. encore ete integree dans le reseau alors qu'un « ancien » module de 
donnees de gestion, associe a une version anterieure de cet equipement, est 
encore charge et que cette version anterieure est toujours integree au reseau, 
il est avantageux de commencer par mettre en attente le nouveau module de 
donnees de gestion qui vient d'etre charge de maniere a poursuivre la gestion 
de Tancienne version de I'^quipement a partir de Tancien module associe et 
charg6, jusqu'a Tintegration de la nouvelle version de I'equipement, puis de 
mettre en service le nouveau module charge lorsque Ton regoit des donnees 
signalant Tintegration de la nouvelle version, de sorte que la gestion de la 
nouvelle version de Tequipement soit assuree a partir de ce nouveau module 
de donnees de gestion 

^invention ne se limite pas aux modes de realisation de procede, 
dispositif de controle 1 et serveur de gestion 2 decrits ci-avant, seulement a 
titre d'exemple, mais elle englobe toutes les variantes que pourra envisager 
rhomme de Tart dans le cadre des revendications ci-apres. 

Ainsi, on a d6crit un reseau dans lequel le systeme de gestion NMS 
ne comportait qu'un unique serveur de gestion equipe du dispositif de controle 
selon rinvention et agence de maniere a gerer Tensemble des equipements 
du reseau. Mais, le systeme de gestion NMS pourrait comporter plusieurs 
serveurs de gestion equip^s chacun d'un dispositif de controle selon 
rinvention et agences de maniere ^ permettre la gestion de parties 



d'equipements du r6seau. 
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REVENDICATIONS 

1. Dispositif (1) de controle de donnees de gestion d'equipements (5) 
d'un reseau de communications comportant un systeme de gestion de reseau 
propre d g^rer lesdits equipements a partir de modules de donnees de 
gestion charges, associes auxdits equipements et stock6s dans une m6moire 
(9), caracteris6 en ce qui! comprend des moyens de controle (10) agences, 
en cas de demande de prise en charge par ledit systeme d'au moins un 
nouvel equipement (5) dudit reseau, pour extraire de ladite memoire (9) le 
module de donn6es de gestion associe a chaque nouvel equipement, puis a 
charger dans ledit systeme chaque nouveau module de donnees de gestion 
extrait, de fagon dynamique, de sorte que la gestion des autres equipements 
(5) dudit reseau par ledit systeme ne soit pas interrompue. 

2. Dispositif selon la revendication 1, caracterise en ce que lesdits 
moyens de controle (1 0) sont agences, en cas de chargement d'un nouveau 
module de donnees de gestion associe a une nouvelle version d'un 
equipement (5), pas encore integree dans ledit reseau, alors qu'un « ancien » 
module de donnees de gestion associe a une version ant§rieure de cet 
equipement (5) est encore charge et que ladite version anterieure est toujours 
integree audit reseau, i) pour mettre en attente ledit nouveau module de 
donnees de gestion charge de maniere a poursuivre la gestion de ladite 
ancienne version de I'equipement a partir dudit ancien module associe et 
charge, jusqu'a integration de ladite nouvelle version de Tequipement (5), 
puis ii), a reception de donnees signalant Tintegration de ladite nouvelle 
version, pour mettre en service ledit nouveau module charge de maniere a 
assurer la gestion de la nouvelle version de Tequipement (5) a partir de ce 
nouveau module de donnees de gestion. 

3. Dispositif selon la revendication 2, caracterise en ce que ladite mise 
en attente consiste, d'une part, a permettre la gestion de la nouvelle version 
de I'equipement (5) a partir dudit nouveau module de donnees de gestion 
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> associ6, sans tenir cx)mpte de messages d'erreur lies a sa non integration 
dans ledit reseau, et d'autre part, a adresser audit ancien module de donnees 
de gestion un message lui signalant qu'un changement de version est en 
cours et qu'il ne doit pas tenir compte d'une partie au moins des messages 
d'erreur lies a la gestion conjointe desdites ancienne et nouvelle versions. 

4. Dispositif selon la revendication 2, caract6rise en ce que lesdits 
moyens de controle (10) sont agences, en cas de synchronisation entre ladite 
nouvelle version d'equipement (5) et ledit nouveau module de donn6es de 
gestion, pour supprimer ledit ancien module de donnees de gestion. 

5. Dispositif selon la revendication 1. caracterise en ce que lesdits 
moyens de controle (10) sont agences pour charger des modules de donnees 
de gestion selon au moins un premier mode dans lequel lesdits modules sont 
charges independamment d'eventuelles dependances entre eux et un second 
mode dans lequel lesdits modules sont charges en tenant compte 
d'eventuelles dependances entre eux. 

6. Dispositif selon la revendication 1, caract6rise en ce que chaque 
module de donnees de gestion est constitue d'au moins un descripteur. 

7. Dispositif selon la revendication 6, caracterise en ce que chaque 
descripteur est constitue d'au moins un fichier de codes de programme et 
d'au moins un fichier de configuration. 

8. Dispositif selon la revendication 7, caracterise en ce que I'un desdits 
fichiers de codes de programme d'un descripteur comporte des premieres 
donnees designant un type auquel appartient un equipement de reseau, et un 
autre desdits fichiers de codes de programme dudit descripteur comporte des 
secondes donnees designant une definition de base d'informations de gestion 
associee audit equipement (5) et accessible audit systeme. 
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9. Dispositif selon la revendication 7, caracterise en ce que lesdits 
codes de programme sont en langage Java. 

10. Serveur (2) de gestion d'un reseau de communications, comprenant 
des moyens de gestion (3) propres a gerer des equipements (5) de reseau a 
partir de modules de donnees de gestion charges, associ^s auxdits 
equipements (5) de reseau et stock6s dans une m6moire (9), caract6rise en 
ce qu'il comprend un dispositif de gestion (1) selon I'une des revendications 
precedentes, couples auxdits moyens de gestion. 

11. Precede de controle de donnees de gestion d'equipements (5) d'un 
reseau de communications, dans lequel on gere lesdits equipements de 
reseau a partir de modules de donnees de gestion charges, associes auxdits 
equipements (5) de r6seau, caracterise en ce qu'en cas de demande de prise 
en charge d'au moins un nouvel equipement (5) dudit reseau, on charge de 
fagon dynamique chaque nouveau module de donnees de gestion associ6 a 
un nouvel equipement (5), de sorte que la gestion des autres equipements (5) 
dudit reseau ne soit pas interrompue. 

12. Precede selon la revendication 11, caracterise en ce qu'en cas de 
chargement d'un nouveau module de donnees de gestion associe a une 
nouvelle version d'un equipement (5), pas encore integree dans ledit reseau, 
alors qu'un « ancien » module de donnees de gestion associe a une version 
anterieure de cet equipement (5) est encore charge et que ladite version 
anterieure est toujours integree audit reseau, i) on met en attente ledit 
nouveau module de donnees de gestion charge de maniere a poursuivre la 
gestion de ladite ancienne version de Tequipement (5) a partir dudit ancien 
module associe et charge, jusqu'a I'integration de ladite nouvelle version de 
Tequipement (5), puis ii), a reception de donn6es signalant {'integration de 
ladite nouvelle version, on met en service ledit nouveau module de donnees 
de gestion charge de maniere a assurer la gestion de la nouvelle version de 
I'equipement (5) a partir de ce nouveau module de donnees de gestion. 
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13. Proc6de selon la revendication 12, caracterise en ce que ladite mise 
en attente consiste, d'une part, a permettre la gestion de la nouvelle version 
de r6quipement (5) a partir dudit nouveau module de donn6es de gestion 
associe, sans tenir compte de messages d'erreur lies S sa non int6gration 
dans ledit reseau, et d'autre part, a adresser audit ancien module de donnees 
de gestion un message lui signalant qu'un changement de version est en 
cours et qu1l ne doit pas tenir compte d'une partie au moins des messages 
d'erreur lies a la gestion conjointe desdites ancienne et nouvelle versions. 

14. Procede selon la revendication 12, caracterise en ce qu'en cas de 
synchronisation entre ladite nouvelle version d'equipement (5) et ledit 
nouveau module de donnees de gestion, on supprime ledit ancien module de 
donnees de gestion. 

15. Procede selon la revendication 11, caracterise en ce que les 
modules de donnees de gestion sont charges independamment de leurs 
eventuelles dependances ou en tenant compte de leurs eventuelles 
dependances. - 

16. Procede selon la revendication 12, caracterise en ce que chaque 
module de donnees de gestion est constitue d'au moins un descripteur. 

17. Procede selon !a revendication 16, caracterise en ce que chaque 
descripteur est constitue d'au moins un fichier de codes de programme et 
d'au moins un fichierde configuration; 

18. Procede selon la revendication 17, caracterise en ce que i'un desdits 
fichiers de codes de programme d'un descripteur comporte des premieres 
donnees designant un type suquel appartient un equipement de reseau, et un 
autre desdits fichier^^ de codes de programme dudit descripteur comporte des 
secondes donnees desigridnt une definition de base d'informatiohs de gestion 
associee audit equipement (5) et accessible. 
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19. Proc6de sejon la revendication 19, caracteris6 en ce que lesdits 
codes de programme sont. en langage Java 

20. Utilisation, des precede, dispositif de controle (1) et serveur de 
gestion (2) selon I'une des revendications prec^dentes dans les technologies 
reseaux devant etre gerees. 

21. Utilisation selon la revendication 20, caract6rise en ce que lesdites 
technologies reseaux sont choisies dans un groupe comprenant les reseaux 
de transmission, en particulier de type WDM, SONET et SDH. de donnees, en 
particulier de type Internet-IP et ATM, et de voix, en particulier de type 
classique, mobile et NGN, 



ABREGE 



DISPOSITIF ET PROCEDE DE CONTROLE DE DONNEES DE GESTION 
D'EQUIPEMENTS DE RESEAU, POUR UN SYSTEME DE GESTION DE 
RESEAU DE COMMUNICATIONS 

Un dispositif (1) est dedie au contrdle de donnees de gestion d'equipements 
(5) d'un reseau de communications comportant ua systeme de gestion de 
reseau permettant de gerer les equipements (5) du r6seau a partir de 
modules de donnees de gestion charges, associ6s auxdits equipements et 
stockes dans une memoire (9). Ce dispositif (1) comprend des moyens de 
controle (10) capables, lorsque le systeme effectue une demande de prise 
en charge d'au moins un nouvel equipement (5), d'extraire de la memoire (9) 
le module de donnees de gestion qui est associe a chaque nouvel 
equipement, puis de charger dans le systeme chaque nouveau module de 
donn6es de gestion extrait, de fagon dynamique, de sorte que la gestion, par 
le systeme, des autres equipements du reseau ne soit pas interrompue. 



(Figure unique) 



